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ABSTRACT 
For the past few years, the Space and Naval Warfare 
Systems Command (SPAWAR) has been developing a 
Naval Architecture Database (NAD) designed to inte- 
grate the Navy’s C4ISR operational, systems, and tech- 
nical architectures in order to support users represented 
by the program managers, systems engineers, and their 
equivalents at other CINCs/Services/Agencies. Several 
systems related applications, models, and tools use this 
architectural information to support C4ISR decision 
making. Each of these applications addresses a different 
and specialized aspect of the systems engineering proc- 
ess. Addressed from an architectural level, it appears 
that most if not all of these applications may be sup- 
ported by the same set of C4ISR systems related data. 
Process and business efficiencies can be realized if a 
centralized information repository is populated in order 
to distribute accurate and timely information to support 
all systems engineering applications. Metadata and pro- 
duction datafills could and should be shared. Once the 
central repository is established, various different sys- 
tems applications may be added to a modular structure, 
easing change management. A fully populated central 
architecture repository could also be used to provide 
decision support systems with the capability to query 
across systems application boundaries to provide man- 
agement with forecasting, trend analysis, and knowl- 
edge-based capabilities combining topics such as fleet 
deployment, systems capabilities, budget modeling, and 
systems architecture. This paper describes the C4ISR 
systems engineering requirements that we have gathered 
and the methodologies that we have applied in building 
a central architecture repository to provide C4ISR sys- 
tems interoperability information. We will describe sev- 
eral initiatives within the Command which require an 
integrated enterprise solution which we will describe in 
the paper. As our project is not completed, the paper 
also includes not only expected benefits, but also issues 


that need to be resolved before a production systems 
interoperability repository is fully functioning. 


BACKGROUND/INTRODUCTION 

The Office of the Chief Engineer at the Space and Naval 
Warfare Systems Command (SPAWAR-05) provides 
unifying management and technical direction for the de- 
velopment, delivery and support of Naval C4ISR sys- 
tems. In order to streamline the Information Technology 
acquisition process of the command, an information in- 
frastructure must be matured to meet the demand of an 
18-month procurement cycle critical to remaining inside 
the commercial technology cycle. C4ISR acquisitions 
must start with an architectural view of the current and 
projected systems implementations to determine where 
and how a new acquisition will fit into the existing infra- 
structure. Figure 1 of the organizational structure of 
SPAWARSYSCOM illustrates the span of responsibility 
and consequently, requirements necessary to support an 
interoperable C4ISR solution, making portions of the 
organization responsible for the system from cradle to 
grave. 
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Figure 1: SPAWAR organization ' 
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REQUIREMENTS 

Architecture is defined in the C4ISR Architecture 
Framework 2.0 ἦ as the structure of components, their 
relationships, and the principles and guidelines govern- 
ing their design and evolution over time. 
Interoperability, as applied to the C4ISR systems engi- 
neering, is defined as “the ability of systems, units, or 
forces to provide services to or accept services from 
other systems, units, or forces and to use the services so 
exchanged to operate effectively together. The condi- 
tions achieved among communications-electronics sys- 
tems or items of communications-electronics equipment 
when information or services can be exchanged directly 
and satisfactorily between them and/or their users.” ἢ 
In C4ISR systems acquisition, several areas require 
authoritative, centralized data: 
Interoperability Analysis 
Budget Modeling 
Systems Capabilities mapping and analysis 
C4ISR Architecture drawings (Ring Charts) 
Configuration management tracking 
Logistics support information 
C4ISR Measures of Effectiveness and Per- 
formance to support Test and Evaluation 

8. Critical system attributes to feed M&S 

9. Tactical tasks performed by C4ISR systems 

10. Systems performance data 
Given the above business requirements to field interop- 
erable systems, we have taken an innovative approach in 
extracting, transforming, and loading critical information 
into a central repository which allows command-wide 
synchronization for the current and planned state of the 
naval C4ISR. This integrated information warehouse and 
repository will allow a global view of C4ISR and allow 
managers to make informed decisions with the depth and 
breadth necessary to maximize the use of critically short 
funding in the Department of Navy today. 


THE METHODOLOGY/ARCHITECTURE 
This project has delineated critical areas in the C4ISR 
acquisition infrastructure that require centralized, nor- 
malized, and integrated information to insure that our 
acquisitions truly follow the SPAWAR mission to “de- 
liver supportable, affordable, integrated, and interoper- 
able world class information solutions.” 


SYSTEMS ARCHITECTURE 
In order to field an interoperable system, a documented 
C4ISR current architecture must exist to understand a 
system’s inter-relationships with other systems. 
Additionally, a target architecture must be developed to 
support the Operational Architecture of the future. A 
Naval Architecture Database’, developed at SPAWAR 
051, containing all the Naval C4ISR Systems, Opera- 
tional, and Technical Architecture views will support 
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C4ISR architecture analysis, both As-Is and Target ar- 
chitectures with fully attributed Information Exchange 
Requirements tied to tactical tasks and the available 
standards used to manipulate and transmit the informa- 
tion. 

The Joint C4ISR Architecture/Planning and Analysis 
System (JCAPS) is a suite of tools. This toolbox allows 
the user to access existing and future C4ISR architec- 
tures and visualize them in the Framework 2.0 format as 
directed by OSD. These architectures will be used to 
support C4ISR Master Plans required in the DoD 5000.2 
process. These operational, system, and technical views 
of the architecture will allow the user to manipulate the 
architecture and understand the ripple effects of pro- 
posed or actual changes to the infrastructure. The Core 
Architecture Data Model 2.0 ° has been mapped to the 
Naval Architecture Data Model 2.1 * with 98% congru- 
ence. This compatibility will allow users of the NAD to 


exchange architecture data with other 
CINCs/Services/Agencies. 
SYSTEMS ENGINEERING 


In order to design a system to inter-operate with several 
legacy systems, a detailed understanding of the installed 
systems must exist. Representations of this complex in- 
frastructure must be simple enough for human under- 


_ Standing of the first and second order effects of a deci- 


sion made within the systems engineering process. The 
use of C4ISR As-Is Architecture drawings called “Ring 
Charts” are used to visualize the relationships between 
systems drilling through a hierarchy starting at the battle 
group level down to a particular component of a plat- 
form. As these drawings are developed, COTS drawing 
packages will generate the data behind these drawings to 
establish the relationships, links, and attributes associ- 
ated with those systems. The example shown in Figure 2 
is representative of a system-level Ring Chart for an air- 
craft carrier. 
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Figure 2: C4ISR Ring Chart 


YEAR 2000 COMPLIANCE (Y2K) 

All current and projected systems must be Y2K compli- 
ant. In order to facilitate compliance, systems must be 
tracked from a centralized location and an up-to-date 
status of the testing stored. Additionally, Memorandums 
of Agreement (MOA) are generated between program 
offices to insure that an agreed interface protocol exists 
to insure that Y2K interfaces are compliant. Integration 
of the Navy-wide Y2K compliance database with the 
C4ISR architecture is critical in understanding the Navy 
infrastructure vulnerabilities. The ability to trace Y2K 
compliance throughout C4ISR architecture should be 
built-in as systems are being added to the Naval Archi- 
tecture Database. 


VISION DOCUMENTS 
There are several visions and proposed architectures that 
need to be mapped against the current C4ISR architec- 
ture in order to develop well planned migration plans. 
ὁ Information Technology for the 21" Century 
Joint Vision 2010 
Copernicus Forward 
Navy Virtual Internet 
Integrated Information Base Architecture 


In order to be truly interoperable with the tactical envi- 
ronment, we need to insure that the infrastructure that 1s 
established in the non-tactical environment will be inter- 
operable with the operational environment. For instance, 
the naming convention (noun name, hull number or 
some defined combination) for fleet units needs to be 
consistent across all systems. 


SYSTEMS MANAGEMENT INTEGRATED 
DATA BASE (SMIDB) 
For the installation of systems to support the Navy Vir- 
tual Internet (NVI), a proposed architecture, and Infor- 
mation Technology for the 21“ Centu 
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Figure 3: SMIDB integration to information warehouse 


a technology insertion program must tie directly to fleet 
capabilities, mission requirements, the UJTLs, and battle 
groups entities. 

A management tool allowing a user to visualize the in- 
teraction among schedule, money, platforms, systems, 
organizations, and capabilities is critical to the planning 
process. In order to fully integrate these information 
sources, data extraction, transformation, and loading 
from several legacy systems must occur in order to 
populate the database. Migration to a centralized re- 
pository as shown in Figure 3 is critical to making the 
system a viable, long-term decision support. 


INTEROPERABILITY EVALUATION 

The Level of Information Systems Interoperability 
(LISI), sponsored by OSD/ASD(C3]) and developed by 
Mitre, is a tool that allows the user to quantify a level of 
interoperability for a system across procedures, applica- 
tions, infrastructure, and data domains. A measure of 
interoperability across all systems is required to under- 
stand where capability holes exist in the procedures, ap- 
plications, infrastructure, and data to support an interop- 
erable environment. SPAWAR is currently evaluating 
the technical! reference model of LISI against several op- 
erational C4ISR systems. A representation of the current 
levels of interoperability 1s shown in Figure 4. This sys- 
tem is planned to be part of the SPAWAR acquisition 
tool kit that is fed with data from the NAD. Results of 
the evaluation will also be archived in the NAD 
throughout the system lifecycle. 
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Figure 4: LISI C4ISR Assessment model ° 


MODELING AND SIMULATION SUPPORT 
The Joint Maritime Systems Analysis Center (JMSAC) 
at SPAWAR PD13 and the Joint Chiefs of Staff (JCS) 
NetWars initiative are attempts to evaluate the perform- 
ance of a C4ISR infrastructure for a specific mission and 


phase of war. The capability to identify infrastructure 
shortfalls in the architecture of a particular battle group 
before a mission is critical to mission planning accuracy. 
Reuse of actual, measured data from exercises around 
the world help model the anticipated message traffic as- 
sociated with a particular mission. This planning can 
identify bottlenecks in the C4ISR infrastructure and pro- 
vide insight into the appropriate technical or operational 
work required to repair the anticipated problems prior to 
experiencing them in the operational environment. 
JMSAC is a COTS based tool that provides simple and 
quick evaluation of existing and to-be C4ISR architec- 
tures. 


BUDGET MODELING 

To ensure that the budget provided by CNO NGE at the 
Program Element (PE) level feed the Work Breakdown 
Structure (WBS) at SPAWAR, we must trace the money 
from the Congressional Budget to actual expenditure of 
assets. Funds must be tied to capabilities by battle group. 
Web-based integration of the Data CUBE database with 
the NAD and SMIDB will feature smart allocation of 
resources to meet current tactical task requirements, and 
further ties budget to existing infrastructure. It is desir- 
able that a Baseline Assessment Memorandum (BAM) 
can be performed on these integrated databases where 
optimal slice and dice of financial resources may be pro- 
posed. 


FLEET EXERCISE 
As-Is C4ISR architecture performance data will be cap- 
tured on operational systems through the Joint Network 
Management System and be used to validate the existing 
database content design assumptions, as well as feed 
scenario based modeling and simulation. 


TYING IT ALL TOGETHER 
The automation of Information Systems management 
and sharing of packaged application data has brought 
substantial and rewarding efficiencies to commercial 
business. These rewards are realized when more timely, 
accurate and comprehensive decisions are possible. 
Without a centralized, normalized, and distributed in- 
formation architecture, critical decisions cannot be made 
on all the associated facts. In order to facilitate a com- 
mon information base for the command acquisition in- 
_ frastructure, we have developed a high-level information 
architecture to tie those disparate data sources together. 
Data warehousing and virtual data base technologies 
combined with web distribution allow smart push and 
pull of the appropriate information to the user. While we 
will be gathering all the critical data elements into the 
data warehouse repository (Figure 5) with a single meta- 
data management area, we will be able to deliver appro- 
priately sized and subject specific aggregations of 


authoritative data to information customers to support 
the various business requirements (Figure 6) throughout 
the Command. The final SPAWAR C4ISR Information 
Warehouse and Repository (SCIWAR) Operating Capa- 
bility architecture is shown in Figure 7. 


BENEFITS 
Each application runs on a data mart produced by the 
data warehouse will have the latest aggregation of in- 


formation to support their business process, to include 
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Figure 5: Migration of information into a repository 
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Figure 6: True ETL using Data Warehouse technology 
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Figure 7: Initial Operating Capability Architecture 


the historical data which allows the added feature of 
trend and time variance analysis. The open system ar- 
chitecture facilitated by standardized information syntax, 
semantics, and web-based distribution technologies is a 
large benefit facilitating more interoperable, Command 
wide tool sets. The fact that new detailed analysis can 
occur with centralized information will provide results 
with more breadth and depth allowing more discrete 
analytical capability. The addition of knowledge base 
and data mining technologies will allow new trends and 
capabilities to be discovered while also adding cognitive 
reasoning capability against an authoritative source of 
information for the command. Once the data warehouse 
infrastructure is fully architected and established, new 
data sources and marts can be rapidly inserted into the 
architecture allowing quick response and access to criti- 
cal information. Additionally, rapid versioning of the 
data marts keeps the business applications current to 
meet the changing business requirements. 


ISSUES 

Several implementation and supportability issues exist in 
our project. The technical feasibility is being verified as 
we are bringing disparate data together. This will be 
demonstrated by a Proof of Concept near the end of this 
calendar year. Information security is a high priority. 
An aggregation of unclassified data can result in a query 
which becomes classified. Multi-level security and row 
level data access may be required to truly automate the 
integrated data environment use and information distri- 
bution. It is critical that data ownership be specifically 
established so that timely and valid system engineering 
data are available to represent diversified, yet integrated 
aspects of C4ISR systems. At the same time, continued 
management support and user involvement are required 
before a Naval Central Architecture Repository for 
C4ISR Systems Interoperability can become a produc- 
tion reality. 


CONCLUSION 

A central information repository is required to achieve 
true interoperability into the C4ISR architecture. 

The current state of technology is available to facilitate 
automated extraction, transformation, and loading of in- 
formation and delivering authoritative, aggregations of 
data to a specific user. Certainly, data warehouse tech- 
nology is one of the major technical solutions to cen- 
trally managing the Command’s metadata requirements 
and increasing the interoperability of information itself 
across the command. 
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